1. Field of the Invention
The present invention relates to mobile communications, and more particularly, to securing communications between a service providing entity and an authoritative entity.
2. Background of Invention
An increasingly large number of individuals use portable computing devices, such as laptop computers, personal data assistants (PDAs), smart phones and the like, to support mobile communications. The number of computing devices, and the number of networks that these devices connect to, has increased dramatically in recent years.
The service provider allowing access to its network usually requires a mobile node and/or a mobile user to authenticate that it is entitled to access the network before it is granted network access. Authentication is the process of identifying a device or user. For example, when logging on to a computer network, user authentication is commonly achieved using a username and password. Authentication is distinct from authorization, which is the process of giving devices or individuals access to services and features based on their identity. Authentication merely ensures that an individual is who he or she claims to be, but does not address the access rights of the individual.
In a typical wireless Internet environment, WiFi based hotspots could be adjacent or distributed in cellular telephone networks. When the services of wireless LAN and cellular networks are integrated, the mobile device (e.g., laptop computer) can move across networks. There are two types of roaming: roaming between the same type of network (e.g., wireless LAN to wireless LAN or cellular network to cellular network) is defined as horizontal roaming; roaming between different types of networks, such as a wireless LAN and a cellular network, is defined as vertical roaming.
In many roaming environments the business entity that is delivering a service and the business entity that is authorizing the service sometimes do not have a direct relationship. Transactions between these entities tend to flow through intermediaries that are trusted in a hop-by-hop fashion. That is, each business entity trusts its neighbor and thus a chain of trust is established.
The chain of trust is formed during authentication where the authentication transaction is routed to the entity performing the authentication through intermediaries that have a trust-relationship with its neighbor until the transaction reaches the authenticating entity. The response of the authentication is routed back over the same path.
During the lifetime of the session the path or the chain of trust over which these transactions transact may change. There are many factors that change the initial trust chain. Intermediaries may fail, or the entity being authenticated may roam into different parts of the network. Furthermore, the intermediaries typically service more then one trust chain.
Trust is an important aspect to the endpoints of these transactions. These transactions affect service in many ways. These transactions can change aspects of the service such as bandwidth or terminate the service. Thus, the entity that is providing service needs to be assured that it is receiving service-modifying transaction from the authoritative entity that is the original authenticating entity or its agent.
In the roaming scenario above, where direct transaction between the service providing entity and the authoritative entity is not possible this assurance is hard to provide.
Authentication, Authorization, and Accounting (AAA) protocols such as Remote Authentication Dial In User Service (RADIUS) and Diameter are typically used to build such systems. The RADIUS protocol defines a message exchange used to authenticate an entity in a roaming environment where the service providing entity (e.g. the Network Access Server (NAS)) is separated from the authoritative entity (e.g. the Home RADIUS server) by intermediaries that only have a direct trust relationship with their immediate neighbors. Furthermore, RADIUS also provides a protocol extension called Change of Authorization (COA) Request and Disconnect Request (DR) for changing the authorization of an ongoing session that is initiated by the authoritative entity.
Change of Authorization Request and Disconnect Request messages are sent from a Dynamic Authorization Client (e.g. RADIUS Server) to a Dynamic Authorization Server (e.g. NAS) to modify attributes of a previously established authentication session or to terminate a previously established authentication session. For RADIUS these are defined by “RFC 5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)” by the Internet Engineering Task Force (IETF), the disclosures of which are hereby incorporated by reference.
RFC5176 provides the following:                Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Request or CoA-Requests affecting the sessions of another provider.        A Dynamic Authorization Server MUST silently discard Disconnect-Request or CoA-Request packets from untrusted sources.        RFC5176 describes one scheme called Reverse Path Forwarding (RPF) where by the receiver of the COA-Request or Disconnect-Request checks to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client.        To perform the RPF check, the Dynamic Authorization Server uses the session identification attributes included in Disconnect-Request or CoA-Request packets, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the CoA-Request or Disconnect-Request is forwarded; otherwise it MUST be silently discarded.        Typically the Dynamic Authorization Server will extract the realm from the Network Access Identifier [RFC4282] included within the User-Name or Chargeable-User-Identity Attribute, and determine the corresponding RADIUS servers in the realm routing tables. If the Dynamic Authorization Server maintains long-term session state, it MAY perform the authorization check based on the session identification attributes in the CoA-Request. The session identification attributes can be used to tie a session to a particular proxy or set of proxies, as with the NAI realm.        Where no proxy is present, the RPF check can only be performed by the NAS if it maintains its own a realm routing table. If the NAS does not maintain a realm routing table (e.g. it selects forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check cannot be performed.        
While this solution works, it has problems in the proxy scenario. First and foremost, routing is not necessarily performed on session identification attributes such as User-Name; routing may be performed on many different attributes present in the access request messages which may or may not appear in the Change of Access or Disconnect messages.
Second, the RPF Check scheme fails in the case where routing may change due to failures or routing optimizations. The current RPF scheme may prevent routing optimizations or failure recovery of the COA-Request and Disconnect-Request. Because any change to the routing paths may not pass the RPF Check. The scheme proposed by this invention allows the COA-Request and Disconnect-Request messages to be routed directly to the NAS or via any intermediary thus allowing for routing path optimizations and circumventing routing failures.
Third, it does not prevent an unauthorized entity that MAY be trusted from injecting a COA or Disconnect Request message. For example, two intermediaries may be valid forwarders of a COA or Disconnect Request messages for a given realm. However, for a given session only the intermediary that was on the authentication path should be the entity that is authorized to forward the COA or Disconnect messages. However, the RPF mechanism does not provide a mechanism to prevent or even detect such unauthorized use.
What is needed are systems and methods that secure communications between a service providing entity and an authoritative entity that are not dependent on message routing.